The present invention relates to a method to have a real time data communication via a real time data over Internet Protocol IP communication network as described in the preamble of claim 1 and to a source and destination realizing such a method as described in the preamble of, respectively, claim 5 and claim 9, and to a communication network that comprises such a source and such a destination as described in the preamble of claim 11.
Such a method, source, destination and real time data over Internet Protocol communication network are known in the art, e.g. from the Request for comments number 1889—from the Networking Group—Category: Standards Track—published on the world wide web at the Internet site:www.ietf.org/rfc/rfc1889.txt?number=1889 with title “RTP: A Transport Protocol for Real Time Applications”. Therein, in paragraph 1, at page 3, a Real Time Transport Protocol RTP that provides end-to-end delivery services for data with real time characteristics is described. The real time data, such as interactive audio and video, is transported in a data flow of Real Time Protocol over Internet Protocol packets. Paragraph 2 of the document, starting at page 5, describes some Real Time Protocol scenario's and paragraph 3, page 7 to page 9 of the document describes the definitions that are used in this technological domain.
The encapsulation of the real time data into RTP packets and furthermore into IP packets is realized in a source. Such a source can be comprised in e.g. a user terminal or a gateway. On the other hand, a destination is enabled to de-capsulate the real time data.
It has to be explained that usually as data of a real time data communication travels across the Internet, a User Datagram Protocol UDP is used to take care of the conversation between the end-to-end entities on the source and the destination. The user datagram protocol UDP encapsulates the RTP packets whereby the UDP packets on its turn are encapsulated into IP packets.
It is known in the art that the main job of the Internet Protocol is to deliver IP packets. However, IP is based on an unreliable connectionless delivery service. So, the user has to install himself additional reliability if a secure service is required. This is for the example of the Real Time Protocol realized by means of RTP Control Protocol reports i.e. RTCP packets. The primary function of these RTCP packets is to provide feedback on the quality of the data that is distributed by the source to the destination. This is described in Section 6 of the above mentioned RFC 1889—more particular on page 14.
In this way receiving time information that is related to a receiving time of a packet is determined by a receiving means of the destination and can be returned by means of such a receiver RTCP report to the source. This is described in section 6.3.1 SR: Sender Report RTCP packet—page 23 to page 26—of the above mentioned RFC 1889.
In this way, a method to have a real time data communication between a first user of a source and a second user of a destination via at least partly a real time data over Internet Protocol communication network comprises the steps of transmitting packets by a transmitting means of the source to the destination and determining by a receiving means of the destination, time information that is related to a receiving time of the packets.
Such a source and/or destination that is enabled to encapsulate and/or de-capsulate real time data into IP packets can be located in the network at different places. Indeed, a source might be comprised in e.g. a terminal of a user i.e. a personal computer or a gateway that acts as a virtual source for e.g. a telephone terminal.
Such a real time data source comprises some pre-configured parameters. Indeed, in order to work according to such a real time data protocol a real time data source comprises some pre-configured parameters such as the data packet-length that is used to generate the real time data protocol packets and the type of codec that is used to encode the real time date. Also the level of echo cancellation of the installed echo chancellor in the source is a pre-configured parameter.
These parameters, among others, are however predetermining a user quality that a user at the destination experiences. Indeed, it has to be explained that a predefined packet length of a real time protocol packet has an impact on the mouth-to-ear delay of the real time data communication. In the event of transporting real time data into smaller packets, less time is needed to encode and to encapsulated the data at the source and less time is needed to de-code and to de-capsulate the data at the destination. A user at the destination will perceive a better user quality. In this way the user quality, predetermined by the design parameters of the source, might be sufficient but might be as well inadequate for the actual real time data communication.
On the other hand, however, the packet size of a real time data packet also has an impact on the gross bandwidth that is used in order to transport a predefined amount of real time data. This means that the real time data bit rate plus the overhead bit rate that is consumed by the real time data communication is bigger in the event of smaller packets. Indeed, in the event of transporting a predefined amount of data as a whole into one real time data packet i.e. one real time protocol packet header with one big packet payload comprising this amount of data, less bandwidth is used since only one packet header is required. In the event of transporting this identical predefined amount of data into different but smaller real time data protocol packets i.e. different packets with each time a packet header and a part of the amount of data, more bandwidth is used since different packet headers are required. Furthermore, besides the used bandwidth to transport the real time data over a communication link, the bandwidth left for data applications that are simultaneously active with the real time data communication is smaller. Such other data applications are e.g. a file transfer or web browsing that is executed in parallel with e.g. a voice communication. It has to be explained here that transporting simultaneously these different data applications over one physical communication link requires a scheduling of the data of these different applications. This scheduling might be performed by different devices in the network e.g. a scheduler comprised in a personal computer or an integrated access device that multiplexes different data streams of different applications into one data stream. According to protocols that are usual installed at such a scheduler or integrated access device, the received real time data gets priority upon the received non-real time data during the scheduling and multiplexing. Hereby it becomes clear that for a predefined smaller packet length of a real time data protocol application that generates a rather big consumption of gross bandwidth, less bandwidth is left for other active data applications.
In this way, it is explained that by choosing and installing the predetermined design parameters of the source, a quality of the real time data communication perceived by the destination is predetermined and also the efficiency of the used bandwidth to transport the real time data is predetermined.